I'd add more cases from #10891, maybe combined into a single test:

contract B {
    function ext() external {}
    function pub() public {}
}

contract C is B {
    function test() public {
        B.ext.selector;
        B.pub.selector;
        this.ext.selector;
        pub.selector;
    }
}

contract D {
    function test() public {
        B.ext.selector;
        B.pub.selector;
    }
}

The problem is that those cannot be done as a semantic test.

Perhaps split into two tests

contract B {
    function ext() external {}
    function pub() public {}
}

contract C is B {
    function test() public returns (bytes4, bytes4, bytes4, bytes4) {
        return (B.ext.selector, B.pub.selector, this.ext.selector, pub.selector);
    }
}
// ====
// compileViaYul: true
// ----
// test() ->

and

contract B {
    function ext() external {}
    function pub() public {}
}

contract D {
    function test() public returns (bytes4, bytes4) {
        return (B.ext.selector, B.pub.selector);
    }
}
// ====
// compileViaYul: true
// ----
// test() -> 0xcf9f23b500000000000000000000000000000000000000000000000000000000, 0x7defb41000000000000000000000000000000000000000000000000000000000

Does the tuple really trigger the same code path? I'll add a syntax test for the others just to be sure.

Does the tuple really trigger the same code path? I'll add a syntax test for the others just to be sure.

Yes, just verified that it does.

Isn't this exactly the case that already worked before?

This file does not trigger an error when run through solc --ir (and I think this is also tested for all syntax tests)

Do we run IR generator on all syntax tests? That's good to know.

Acutally we do not. We compile to bytecode, but not via yul. I just tried it and it is kind of stuck in the optimizer :(

Do we run IR generator on all syntax tests? That's good to know.

Not yet.

Just ran the IR on all syntax tests and found one unimplemented feature: #11024

We did that a few weeks ago already (it used to be more like 9 cases or so), so that issue may be a duplicate...

I couldn't find an equivalent issue. We probably missed that one. this was the CI job https://app.circleci.com/pipelines/github/ethereum/solidity/13394/workflows/42f7aa23-443b-4847-be5e-b37f8af856b3/jobs/621452/tests#failed-test-2

Weird... I do remember that we were wondering if it actually works and that I noted that it's a bit weird even in old codegen... but maybe we still didn't do anything about it or even file an issue :-).